Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-pip-identifiers-02.txt

Text File | 1993-06-18 | 11KB | 344 lines

Network Working Group                                         P. Francis
INTERNET-DRAFT                                    (formerly P. Tsuchiya)
                                                                Bellcore
                                                               June 1993


                            Pip Identifiers


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts).

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.


Abstract

   Pip is an internet protocol intended as the replacement for IP
   version 4.  The Pip header defines source and destination ID fields
   whose primary function it is to identify the source and destination
   of a Pip packet.  While Pip systems treat the IDs as flat for the
   purpose of identification, it is useful to have hierarchical
   structure in the ID for other purposes, such as for doing a reverse
   DNS lookup on the ID.  This internet-draft defines the structure of
   Pip IDs.



1.  Changes From Previous Version

   The previous version is dated January 1993.  Following is a summary
   of changes from that version.




Pip WG, Expires December 1, 1993                                [Page 1]






INTERNET-DRAFT              Pip Identifiers                    June 1993


   1.   A code point was added for "local" IP address.  This is an IP
        address that is not guaranteed to be globally unique.  With this
        code-point, a system can assign itself an ID based on its IP
        address, but the ID will only be unique within the systems "IP-
        unique" domain.  As long as all IP addresses are unique, the ID
        will also be unique.

   2.   A section describing Pip ID notation was added.

   3.   The ASN.1 style of assignment was removed.  This results in the
        Pip ID hierarchy not being self describing.  This is the result
        of a general notion that Pip IDs should largely be considered
        flat entities, and in particular that Pip systems should use an
        Ethernet number to derive their Pip IDs.  Because the ASN.1
        style of assignment was removed, all of the previous assignments
        are different.




2.  Introduction

   Pip is an internet protocol intended as the replacement for IP ver-
   sion 4.  The Pip header defines source and destination ID fields
   whose function, in the context of host processing of Pip headers, is
   to only identify the source and destination of a Pip packet.  While
   Pip systems treat the IDs as flat for the purpose of identification,
   it is useful to have hierarchical structure in the ID for other pur-
   poses, such as for doing a reverse DNS lookup on the ID.  This
   internet-draft defines the structure of Pip IDs.

   Pip IDs have the following characteristics:

   1.   With well-known exceptions, they are globally unique binary
        strings 8 octets in length.

   2.   While they are hierarchically structured for assignment pur-
        poses, the Pip layer does not treat them as hierarchical.
        Further, assignments are set aside for such addresses as IEEE
        802, resulting in what is effectively a flat ID.

   3.   Each component of the hierarchy is contiguous, and each
        hierarchical component is positioned in the Pip ID adjacent to
        its parent and child components.




Pip WG, Expires December 1, 1993                                [Page 2]






INTERNET-DRAFT              Pip Identifiers                    June 1993


   4.   Each level of the hierarchy can fall on an arbitrary bit boun-
        dary.

   5.   Pip IDs may be used for group identification, but such a Pip ID
        is not self-describing as being a group Pip ID.

   6.   Certain Pip IDs are well-known and have local meaning, such as
        "all routers on the subnet" and "this host".

   Pip IDs are formed by a hierarchy of number authorities, each of
   which is responsible for assigning the next lower level of the
   hierarchy.  Generally it is the intent that Pip IDs be treated as
   flat, and that the hierarchy is solely for the purposes of insuring
   uniqueness.  In particular, it is not assumed that an inverse DNS
   lookup on the Pip ID works.

   To the extent that the hierarchy in a Pip ID is exploited for other
   purposes, it is recommended that the hierarchical structure of Pip
   IDs follow administrative hierarchy (versus, for instance, topologi-
   cal hierarchy).  It is up to each number authority to determine how
   the next level is assigned.

   I should be noted that some people are of the opinion that Pip IDs
   (or, network layer IDs in general) should have organizational
   hierarchical content that might be used for accounting of various
   kinds, inverse DNS lookups, and perhaps other things.  Bob Smart and
   John Curran in particular have put forth arguments to this effect,
   and were acknowledged in the first draft of this document, which
   embraced their philosophy.  Since then, I have become concerned that
   this placed too many constraints on Pip IDs, in particular with
   regards to auto-configuration of hosts, and the need to change Pip
   IDs when a host changes organizations.  However, the issues of organ-
   izationally meaningful Pip IDs versus flat Pip IDs is still an open
   one.  This specification does not prohibit the creation of organiza-
   tionally meaningful Pip IDs, should that be found useful by various
   organizations or across the board.



3.  Pip ID Notation

   This section describes a uniform method to write Pip IDs.  This
   method should be used whenever Pip IDs are written or typed.  In par-
   ticular, all software used to read or write Pip IDs should use this
   notation.



Pip WG, Expires December 1, 1993                                [Page 3]






INTERNET-DRAFT              Pip Identifiers                    June 1993


   A Pip ID is written as a sequence of 8 2-digit hex numbers separated
   by dots.  Leading 0's are written.



4.  Assigned Top-level Pip ID Numbers

   The top-level assignment authority (as yet unspecified, but IANA, the
   Internet Assigned Numbers Authority, seems to be a logical candidate)
   is responsible for assigning prefixes (the most significant bits) of
   the Pip ID.  By assigning a prefix, the top-level authority creates a
   block of addresses, the authority of which is handed to another
   organization.

   The following Pip ID assignments are defined:



4.1.  CCITT E.164

   A CCITT E.164 address can be used to create a globally unique Pip ID.
   Thus, anybody with an E.164 address can use it to form a globally
   unique Pip ID.  All Pip IDs formed from E.164 address have the form:

   | 14-bit prefix |---50 bits---|
   |00000000 000000| E164Address |

   That is, 14 bits of value 0, followed by the E.164 address, converted
   to binary (note this is not BCD encoding, but strict binary).  50
   bits is adequate to encode all E.164 addresses in binary.



4.2.  IEEE 802 Address

   An IEEE 802 address can be used to create a globally unique Pip ID.
   Thus, anybody with an IEEE 802 address can use it to form a globally
   unique Pip ID.  All IEEE 802 based Pip IDs have the format:

   (hex) 80.00.IEEE802address

   That is, the first 16 bits are (hex) 8000, followed by the 48 bit
   IEEE 802 Address.  Thus, the valid range of IEEE 802 based Pip IDs
   is:




Pip WG, Expires December 1, 1993                                [Page 4]






INTERNET-DRAFT              Pip Identifiers                    June 1993


   80.00.00.00.00.00.00.00 to 80.00.ff.ff.ff.ff.ff.ff.



4.2.1.  Locally Unique ID

   If a host has no IEEE 802 address, it can create a locally unique
   (local to the subnet) Pip ID using the IEEE 802 prefix.  To do this,
   the local subnet address is placed in the low order part of the Pip
   ID, and the remaining bits of the 48-bit space are filled in ran-
   domly.



4.3.  Local IP Domain

   A Pip ID can be formed from an IP address.  As long as IP addresses
   are globally unique, a Pip ID formed from an IP address is also glo-
   bally unique.  All IP Address based Pip IDs have the format:

   (hex) 40.00.00.00.IPaddress

   That is, the first 32 bits are 40.00.00.00, followed by a 32-bit IP
   Address.  Thus, the valid range of IP based Pip IDs is:

   40.00.00.00.00.00.00.00 to 40.00.00.00.ff.ff.ff.ff.



4.4.  Flat Well-Known IDs

   There are any number of uses for identifying systems of a certain
   type, rather than specific systems.  For instance, an ID for "all
   routers on the LAN" is useful for router discovery.  This specifica-
   tion defines the following well-known Pip IDs.  These well-known Pip
   IDs consist of a single hierarchy level (the top-level), but are so
   large that only one level of hierarchy is possible.

      Any Router = ff.ff.ff.ff.ff.ff.ff.fe

      Any Host = ff.ff.ff.ff.ff.ff.ff.fd

      Any System = ff.ff.ff.ff.ff.ff.ff.fc

   The above three well-known Pip IDs serve for functions such as "all



Pip WG, Expires December 1, 1993                                [Page 5]






INTERNET-DRAFT              Pip Identifiers                    June 1993


   routers on a subnet", for instance in configuration algorithms such
   as router discovery.  Other well-known Pip IDs are expected to be
   defined in the future.



4.5.  Country Codes

   While it is expected that most hosts will obtain their Pip ID from an
   IEEE802 address (either from their interface card from from their
   CPU), it may be necessary to obtains IDs from other sources.  For
   this purpose, a 32-bit block of IDs have been assigned to each coun-
   try.  The countries can further assign blocks to organizations if
   desired.  It should be noted that Pip systems with an assignment from
   a country's block is in no way constrained to reside in that country.

   Pip IDs formed by country code have a prefix of:

   |------22 bit prefix-----|--10 bits---|----32 bits---|
   |11000000 00000000 000000|  ISO 3166  |   remainder  |

   ISO 3166 is the ISO standard for country codes.  All country codes
   are between 0 and 999 (decimal), so 10 bits are adequate.  The coun-
   try codes are encoded in binary when in the Pip ID.

   It is recognized that, in the long run, 32 bits per country will not
   be adequate.  When countries need more code space, it can be allo-
   cated at that time.  It is likely that we will have a better idea of
   ID assignment needs at that time.



















Pip WG, Expires December 1, 1993                                [Page 6]